Letztes Update:
21. September 2023
Entwurf – Inhalt noch in Arbeit
Symbolbild
Wenn es bei Eingaben bzw. Auswahlen von Daten zu Problemen bzw. Fehlern kommt, informieren und unterstützen Feedbackmeldungen den Nutzer über aufgetretene Probleme und die nötige Form von Dateneingaben, weisen auf notwendige Korrekturen hin bzw. geben Hinweise die helfen, Fehler zu korrigieren (Korrekturvorschläge).
z.B. Fehlermeldungen bei Formularfeldern, 404er und 500er Sites bei Suchen oder Navigation
Fehlermeldungen bei Interaktionen können in manchen Fällen auch Bestätigungen bei korrekten Eingaben enthalten.
In erster Linie sollen die Interaktionen derart gestaltet sein, dass es dem Nutzer kaum möglich ist Fehler zu machen. Sollte es trotzdem zu Fehlern durch den Nutzer kommen, müssen diese derart kommuniziert werden, dass diese für den Nutzer klar erkennbar sind und er diese problemlos beheben kann.
→ Einfluss auf die Conversion-Rate!!
siehe Eingabehilfen unter „Formulare: Eingabe und Auswahl von Daten – Grundlagen„
Der Nutzer soll durch Inline-Validierung bereits vor dem Auftreten eines Fehlers beim Absenden auf diesen aufmerksam gemacht werden.
Dabei wird noch während des Ausfüllens durch den Nutzer die Eingabe geprüft und bei möglichen Fehlern darauf hingewiesen.
Darstellung, Positionierung und Inhalt der Fehlermeldung sind dabei die gleichen wie nach dem Absenden der Interaktion.
Dabei wird das jeweils durch den Nutzer aktiv gesetzte Feld während der Eingabe bzw. bei Verlassen des „Aktiv-Status“ validiert.
Es sollte nicht sein dass bei Aktiv-Setzung eines Feldes sofort alle Felder Validiert werden.
Besonders wichtig sind Echtzeit-Validierungen bei Feldern wie Passwörtern, Email-Adressen, Mitgliedsnamen, …..
Standardangaben wie Namen sollten dabei nicht in Echzeit validiert werden.
Die fehlerhafte Eingabe wird sofort nach dem Ausfüllen durch den Nutzer ersichtlich gemacht, nicht erst beim Absenden des Formulars. Die Validierung in Echtzeit kann dabei dynamisch anzeigen welche Richtlinien für das Eingabefeld – beispielsweise eines Passwort setzen Feldes – noch nicht erfüllt sind. Beispielsweise „Passwort muss X Zeichen enthalten“, gefolgt von „Passwort muss Sonderzeichen enthalten“….
In diesem Zuge können auch Korrekturvorschläge gezeigt werden – beispielsweise zur Eingabe ähnliche, noch verfügbare Nutzernamen.
Formulare mit denen Nutzer Daten zur Speicherung und Verarbeitung übertragen können benötigen die Möglichkeit die eingegebenen Daten vor dem Absenden:
zu kontrollieren,
zu ändern bzw.
deren Eingabe rückgängig zu machen
und eine Option um das Absenden zu bestätigen.
Es dürfen keine Daten direkt bei der Eingabe übertragen bzw. verarbeitet werden. Clientseitige? Inlinevalidierung ausgenommen.
Formulare bzw. Datenauswahlen bzw. -eingaben mittels denen der Nutzer mit den Inhalten einer Seite interagiert, benötigen keine Option zur Kontrolle bzw. Änderung vor dem Absenden. Diese Eingaben können jederzeit problemlos auch nach dem Absenden wiederholt bzw. rückgängig gemacht werden. z.B. Filter setzen, suchen, merken, bewerten,….
Erfolgt die Fehlermeldung nach dem Absenden des Formulars durch den Nutzer, wird das Formular inklusive aller Nutzereingaben (auch der fehlerhaften) nochmals gezeigt.
Ausnahme: Passwörter, diese müssen aus Sicherheitsgründen nochmals eingegeben werden.
Fehlerhafte Eingaben werden optisch und technisch (wie beschrieben) markiert und mit einem hilfreichen Fehlertext versehen.
Fehlermeldungen immer in direkter Nähe zum Eingabefeld zeigen bei welchen der Fehler aufgetreten ist. Nicht am Beginn oder Ende des gesamten Formulars!
Sendet ein Nutzer ein Formular ab bei dem es zu Fehlern kommt muss zusätzlich ein Autoscroll-Funktion zum ersten aufgetretenen Fehler und dessen Fehlermeldung scrollen. Auch der Fokus wird in das erste fehlerhafte Feld gesetzt.
Fehlermeldungen und Hilfestellungstexte sind in der Auszeichnung mittels dem aria-describedby Attribut mit dem zugehörigen Textfeld verknüpft.
Genannte Korrekturmöglichkeiten nehmen möglichst genauen Bezug auf die Eingabe des Nutzers.
Dies erfordert, auch dass pro Feld mehrere Fehlermeldungen möglich sein müssen – je nachdem welche Validierung fehlschlägt.
Zusätzlich benötigt es bei speziellen Feldern auch die Funktion, dem Nutzer Möglichkeiten zur Eingabe vorzuschlagen. (z.B. bei einem bereits vergebenen Benutzernamen noch verfügbare Möglichkeiten vorschlagen, oder Hinweise geben wie ein Passwort zusammengesetzt sein muss, eventuell sogar Passwörter für den Nutzer zu generieren)
Die Kennzeichnung von fehlerhaft ausgefüllten Eingabefeldern muss optisch deutlich erkennbar sein. Farbe darf hier nicht das ausschließliche Mittel für die Hervorhebung.
Direkt unter dem jeweiligen Feld steht die Fehlermeldung.
Fehlermeldungen werden mit dem Attribut aria-describedby mit dem Dropdownfeld verbunden.
Die Kennzeichnung von korrekten Eingaben muss optisch deutlich erkennbar sein. Diese darf nicht nur durch eine Farbe realisiert werden.
Aktuell noch nicht im Einsatz.
Definition folgt (voraussichtlich vor allem für das Passwortfeld beim Registrieren relevant)
Auf den Plattformen und in E-Mail Nachrichten wie beispielsweise Newslettern kommen Schemata für strukturierte Daten zum Einsatz. Diese ermöglichen unter anderem Anwendungen von Google, Microsoft, Pinterest etc. mittels dieser Informationen reichhaltigere und für die Nutzer passende Inhalte anzuzeigen.
Einführung in das Markup für strukturierte Daten in der Google Suche
Details zu den für Plattformen und E-Mail Nachrichten zu verwendende Schemata:
Die Richtlinien für barrierefreie Webinhalte (WCAG) beinhaltet Prinzipien, Richtlinien und Erfolgskriterien um Webinhalte barrierefreier zu gestalten. Die Grundlagen zur Zugänglichkeit sind in der Guideline eingearbeitet. Details finden sich unter Richtlinien für barrierefreie Webinhalte WCAG.
ARIA-Spezifikationen sind eine definierte Semantik für Barrierefreiheit und wird verwendet, um barrierefreie Webumgebungen zu erstellen. Anleitungen, Muster und funktionale Beispiele finden sich unter https://www.w3.org/WAI/ARIA/apg/.
Bezüglich der Security für vorliegendes Element siehe die „Sicherheitsrichtlinie No. 2023/xxxx Webanwendungen & Webservices Programmierung & Server-Konfiguration“ (ausschließlich intern zu erreichen).
Wenn es nach Interaktionen zu Fehlern kommt, benötigen diese eine zugängliche Darstellung und aussagekräftige Beschreibungen.
Diese beeinflussen ob Nutzer die Interaktion abbrechen und helfen entstandene Fehler effizient zu beheben und die Dateneingabe/Interaktion erfolgreich abzuschließen.
Es gelten die allgemeinen Regeln zu Text formulieren – interessant, verständlich und vertrauenswürdig schreiben und folgende spezifische Vorgaben:
Erhält der Nutzer eine Fehlermeldung (die möglichst derart optimiert ist, dass er sie rasch wahrnimmt und zuordnen kann), muss verständlich, klar und eindeutig sein, was genau der Fehler ist und was der Nutzer tun kann um den Fehler zu beheben.
Was ist der Fehler? den Grund des Fehlers klar und verständlich benennen – Nutzer muss verstehen was schief gegangen ist. z.B.
Was muss der Nutzer tun bzw. wie muss die richtige Eingabe aussehen? Hilfestellung zur Fehlerbehebung. Nutzer muss verstehen was er tun kann. (z.B. Bitte wählen Sie einen verfügbaren Benutzernamen)
Korrekturmöglichkeiten anzeigen, die genau Bezug auf die Eingabe des Nutzers nehmen. (z.B. bei einem bereits vergebenen Benutzernamen noch verfügbare Möglichkeiten vorschlagen, oder Hinweise geben wie ein Passwort zusammengesetzt sein muss)
Keine technischen Formulierungen oder Zahlenkombinationen als Fehlerkennzeichen
nicht von “Fehler” oder “Problem” schreiben
keinen Vorwurf machen – höflich und freundlich texten. Don`t: Sie haben dies und jenes eingegeben… Geben Sie nicht das und das ein….
Achtung – auch Fehlermeldungen in die jeweilige Sprache der Plattformen übersetzen